Skip to content

fix: claim state_sync_requested with compare_exchange#3891

Open
iho wants to merge 1 commit into
mimblewimble:stagingfrom
iho:fix/state-sync-requested-cas
Open

fix: claim state_sync_requested with compare_exchange#3891
iho wants to merge 1 commit into
mimblewimble:stagingfrom
iho:fix/state-sync-requested-cas

Conversation

@iho

@iho iho commented Jul 9, 2026

Copy link
Copy Markdown

Summary

Fixes #3588.

When handling TxHashSetArchive, the code used a non-atomic check-then-clear:

if !state_sync_requested.load(...) { return Err(...) }
state_sync_requested.store(false, ...)

Two concurrent archive messages could both observe true and proceed.

Change

Use compare_exchange(true → false) so only one handler claims the outstanding state-sync request.

Test plan

  • cargo test -p grin_p2p --lib -- --test-threads=1

Replace separate load/store when accepting a TxHashSetArchive with an
atomic compare_exchange so two concurrent messages cannot both observe
the flag as true. Addresses mimblewimble#3588.
Comment thread p2p/src/protocol.rs
// and proceed (load+store race; see #3588).
if self
.state_sync_requested
.compare_exchange(true, false, Ordering::SeqCst, Ordering::Relaxed)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue #3588 raised a static analysis concern about another thread updating the flag between the load and store. The race described in this PR does not appear reachable, since archive responses from a peer are processed one at a time. Could we clarify which concrete interleaving this fixes? If it is a delayed response overlapping a newer request, this boolean still cannot tell them apart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants